物理机网络高可用
网卡高可用
ZStack Cloud云平台使用bond技术可以将多个网卡绑定到一起，可以让两个或多个接口作为一个接口，同时提高带宽，并提供网络链路的冗余，当有其中一块网卡故障的时候，不影响物理机网络使用，云主机无感知。
- 模式1（mode=1，active-backup）：此模式使用主被策略（热备）。
- 在所有做bond1的物理网卡中，同一时刻只有一张网卡被激活，当且仅当活动网卡失效时才会激活其他的网卡。
- 这种模式下做bond的两张或多张网卡的MAC地址和Bond虚拟网卡的MAC地址相同，而Bond的MAC地址是Bond创建启动后活动网卡（Active Slave）的MAC地址。
- 这种模式要求主被网卡能快速的切换，即当主网卡出现故障后能迅速地切换至备用网卡。
- 切换过程中，上层的应用几乎不受影响，因为Bond的驱动程序会临时接管上层应用的数据包，存放至数据缓冲区，等待备用网卡启动后再发送出去。
- 但如果切换时间过长，则会引起缓冲区的溢出，导致丢包。
- 模式4（mode=4，802.3ad）：使用动态链接聚合策略，启动时会创建一个聚合组，所有Slave网卡共享同样的速率和双工设定。
推荐使用bond1主备模式或bond4的动态链路聚合的方式保证物理机网络高可用，并提供快速配置bond命令如下：
[root@localhost ~]# zs-bond-lacp -c bond0 #创建链路聚合模式的Bond0
[root@localhost ~]# zs-bond-ab -c bond1 #创建主备模式的Bond1
[root@localhost ~]# zs-nic-to-bond -a bond0 eth0 #绑定网口eth0到对应bond0
[root@localhost ~]# zs-nic-to-bond -a bond0 eth1 #绑定网口eth1到对应bond0
[root@localhost ~]# zs-nic-to-bond -a bond1 eth2 #绑定网口eth2到对应bond1
[root@localhost ~]# zs-nic-to-bond -a bond1 eth3 #绑定网口eth3到对应bond1
[root@localhost ~]# zs-vlan -c bond0 10 #为bond0创建VLAN标签10
[root@localhost ~]#zs-network-setting -b bond0 192.168.1.100 255.255.255.0 192.168.1.1 #为bond配置IP地址
如果网络配置错误，请使用如下步骤清理配置错误的网络重新配置：
[root@localhost ~]# ip link set br_XXX down #停止创建的网桥
[root@localhost ~]# brctl delbr br_XXX #删除网桥
[root@localhost ~]# rm -f /etc/sysconfig/network-scripts/ifcfg-br_XXX #删除网桥配置文件
[root@localhost ~]# zs-vlan -d bondX XX #删除vlan子接口
[root@localhost ~]# zs-nic-to-bond -d bond0 eth0 #从bond中移除对应网口
[root@localhost ~]# zs-bond-ab -d bondX #删除错误的bond
DHCP高可用
DHCP是一个局域网的网络协议。指的是由服务器控制一段IP地址范围，登录服务器时就可以自动获得服务器分配的IP地址和子网掩码， DHCP协议采用客户端/服务器模型，当DHCP服务器接收到来自网络主机申请地址的信息时，才会向网络主机发送相关的地址配置等信息，以实现网络主机地址信息的动态配置，传统的DHCP技术当DHCP服务器异常，将无法分配IP地址。
ZStack Cloud云平台采用分布式DHCP技术，使用dnsmasq来实现分布式的DHCP，使得DHCP的服务端存在多个主机上，每个DHCP server对应一个三层网络，并只对该三层网络提供服务，并且每个主机只对该物理主机上的云主机提供服务，三层网络在每个主机上都会存namespace，用于高效的地址分发和地址管理，当管理节点故障时也不会影响云主机的DHCP使用。
工作原理：
虚拟机启动时，管理节点把虚拟机的的IP/MAC/DNS等信息发送给kvmagent,，kvmagent把配置写入本地对应DHCP server的配置文件。
虚拟机启动后，发出DHCP广播请求，根据物理机上配置的ebtables规则，虚拟机的DHCP请求报文被drop，报文就不会从物理网卡转发出去，而是发给本地DHCP server，本地的DHCP server收到请求后， 查询本地的配置文件是否有此ip，MAC 的对应配置，如果有就会响应该请求。
VPC路由器高可用
ZStack Cloud云平台采用VPC路由器来提供VPC网络， 用于提供多种网络服务。包括虚拟IP，弹性IP，IPsec隧道，端口转发，负载均衡，DHCP等服务，同时支持设置组播路由。VPC路由器支持内外部全方面实时监控，并提供配套报警服务，同时支持设置跨集群高可用策略，充分保障网络核心资源高可用性。
ZStack Cloud云平台采用VPC路由器高可用组来保证VPC网络的高可用性，即一对互为主备的VPC路由器，当主VPC路由器状态异常，自动切换至备VPC路由器，为业务高可用提供保障。
约束条件
- 增加或删除网络 ，修改任一VPC路由器，将同步修改高可用组中全部路由器。
- 配置网络服务：EIP、PF、LB、IPsec、VipQos、 DNS、 SNAT、 OSPF、 Multicast以及分布式路由 ，修改任一VPC路由器，将同步修改高可用组中全部路由器。
- 重启、重连、删除、打开控制台仅对一路由器生效。
- 创建VPC路由器前，须提前创建路由器规格所需的公有网络和管理网络、路由器镜像资源，无法使用扁平网络。
- 添加至VPC路由器高可用组前需停止该VPC路由器。
- 高可用组内的VPC路由器将只展示在高可用组详情页中，在路由器列表不单独展示 。
- VPC路由器需要使用宿主机计算资源及存储，建议VPC路由器高可用组中的路由器分布在不同物理机上。
- 建议单个VPC路由器上的VPC网络和公有网络数量不超过23个。网络数量过多可能会造成VPC路由器性能下降，影响相关网络服务质量。
- 由于所有网络服务共享物理网卡的带宽，单个VPC路由器上承载过多虚拟IP可能造成网络性能瓶颈。建议使用虚拟IP创建网络服务时，根据实际业务带宽需求，合理规划虚拟IP数量。
VPC高可用组的设计
1. VPC的API配置分为配置变化和状态变化。配置变化同时配置到Master和Backup路由器； KeepAlived监控zvr进程，如果异常，会主动切换到BackUp状态，保证云平台和Vyos都处于backup状态。
2. 正常情况，Master和Backup处于Connected/Connecting的状态。
- 首先配置到master路由器，成功以后API返回，使用gc job延时配置到BackUp路由器。
- 所有的gc job按照顺序执行，不能并发执行。
- 虚拟路由器在重连过程中，会把所有的配置下发到vyos, 但是在重连的过程配置可能发送变化，因此在connecting状态依然需要使用gc job 和master同步配置。
- 当backup进入disconneted状态，会取消所有的gc job，因为此时可能一直不成功，浪费cpu资源。
- 当虚拟路由器被删除，则所有的gc job也会被取消。
3. 高可用路由器的接口IP。
- 管理网路：两个路由器的接口随机分配。
- public网络：
- 如果public网络和管理网路相同，额外从管理网分配一个地址，作为Vip。
- 如果public网络和管理网路不同，两个路由使用相同的接口地址。
- 私有网络：两个路由器的接口都是用网络的网关地址。
4. 普通路由器升级到高可用组。
- 升级路由器和创建新的路由器，不能并发执行。
- 导入的VPC路由器需处于停止状态。
- 导入操作将同步导入已有VPC路由器的全部配置，导入后将无法作为独立VPC路由器使用，请谨慎操作。
- 仅支持公有网络和系统网络分离的VPC路由器加入高可用组。
5. Vyos的状态变化。
- Vyos使用keepalived进行主从协商。在如下情况下，会发生状态切换。
- 主vyos被关机/重启了，在一般情况下，keepalived会发送graceful restart的报，backup路由器会及立即变成master。
- master的monitor ip不通，但是Backup的Monitor ip可以通，backup路由器会及立即变成master。
- master的网络中断，Backup收不到来自master vrrp包，超时后，backup切换到master, 切换时间3~5秒。
- vyos的状态变化以后，会立即发送到master，但是如果主vyos关机/重启，会来不及发送，会导致出现两个master，直到关机/重启完成。
- 重连可能会导致主备切换，原因是在master vyos重连过程,会重启keepalived. 可能会导致主备切换。